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CHAPTER  1 
INTRODUCTION 

1.1  PURPOSE 

This  report  documents  the  results  of  software  enhancement 
and  version  release  test  support  for  the  DSCS  Network 
Performance  Software  (DNPS).  This  effort  was  addressed  through 
three  subtasks. 


Subtask  A:  Requirements  Analysis  Development  and  Test 


The  purpose  of  this  subtask  was  to  analyze  software/ 
hardware  change  requirements  resulting  from  either  operational 
\tilization  of  the  DSCS  Operational  Control  System  (DOCS)  re¬ 
sources  or  the  evolutionary  development  of  the  control  system. 


Subtask 


Version  Release  Test 


The  purpose  of  this  subtask  was  to  support  version  release 
tests  for  the  DNPS  software  in  order  to  ensure  that  no  major 
software  logical  errors  or  engineering  modeling  errors  were 
introduced  during  the  upgrade  from  one  software  version  to 
another . 


Subtask  C:  Integration  of  Multi] 


Beam  Antenna  (MBA) 


Resource  Allocator 


The  purpose  of  this  subtask  was  to  refine  the  MBA 
allocation  algorithm  developed  under  the  previous  year's 
tasking  to  test  the  algorithm  and  to  integrate  the  algorithm 
into  the  DNPS  software  resident  at  the  DCEC  computer  facility. 


1.2  REPORT  ORGANIZATION 


Chapters  2,  3,  and  4  of  this  report  summarize  the  efforts 
on  these  subtasks.  Detailed  results  are  provided  in  the 
primary  subtask  reports  previously  delivered  under  this  task 
[Refs.  2,  3,  4,  and  5]. 
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SUBTASK  A: 


2.1  PURPOSE 


CHAPTER  2 

REQUIREMENTS  ANALYSIS,  DEVELOPMENT,  AND  TEST 


The  purpose  of  this  subtask  was  to  provide  software 
development  and  test  support  for  the  DNPS  based  on  potential 
computer  hardware/software  change  requirements  identified  as  a 
result  of  either  operational  utilization  of  the  DOCS  resources 
or  the  evolving  development  of  the  DSCS  control  system.  These 
requirements  were  to  be  analyzed,  modifications  recommended  to 
the  software/hardware  (and/or  new  software/hardware 
recommended),  and  the  changes  implemented  and  tested. 

2.2  SUMMARY  OF  RESULTS 

This  subtask  was  not  activated.  At  the  request  of  the  COR 
(L.  Krebs) ,  funds  for  this  subtask  were  directed  to  provide 
enhanced  support  for  subtasks  B  and  C. 


CHAPTER  3 

SUBTASK  B:  VERSION  RELEASE  TEST  SUPPORT 


3.1  PURPOSE 

This  test  report  documents  results  of  the  DNPS  validation 
and  verification  testing  effort.  This  testing  is  part  of  the 
continuing  support  provided  by  M/A-COM  Government  Systems, 

Inc.,  to  the  Defense  Communications  Engineering  Center  (DCEC) . 

The  testing  effort  focused  on  three  areas: 

1.  Comparison  of  test  scenarios 

2.  Comparison  of  version  test  results 

3.  Identification  of  procedural  problems. 

The  first  area  refers  to  the  ability  of  DNPS  to  run  the 
same  (or  nearly  the  same)  test  scenarios  as  the  previous 
version  software.  This  is  important  if  accurate  comparisons 
between  versions  are  to  be  made.  The  second  area  concerns  the 
key  question  to  be  answered  by  this  test  effort:  will  the  new 
version  software  produce  the  same  results  as  previous  version 
software?  Finally,  any  procedural  difficulties  and/or  software 
anomalies  encountered  were  documented  in  the  form  of  software 
user  reports  (SURs) .  These  SURs  were  delivered  as  generated 
and  are  listed  in  References  1,  2,  and  3. 

In  all,  three  versions  of  DNPS  were  tested: 

•  DNPS  Version  3.1 

•  DNPS  Version  3.2 

•  DNPS  Version  4.0 

The  following  subsections  summarize  the  test  methodology  and 
the  results  obtained. 


3.2  TEST  METHODOLOGY  AND  MEASUREMENT  CRITERIA 


The  overall  test  methodology  is  shown  in  Figure  3-1. 
M/A-COM  began  by  verifying  that  the  static  testing  on-line  data 
base  was  consistent  between  DNPS  versions.  This  data  base 
contains  information  such  as  satellite  data  (e.g.,  latitude/ 
longitude,  channel,  EIRP)  and  modem  data  (e.g.,  type,  P^  Vs. 

Eb/N0) •  Next,  three  test  scenarios  were  run  and  results 
were  gathered  both  for  the  current  and  new  versions  DNPS. 

These  resuls  were  analyzed  to  determine  how  closely  the  new 
version  results  matched  the  current  version  results.  Finally, 
any  large  discrepancies  were  noted  and,  where  possible,  traced 
to  a  software  module  or  routine. 

In  the  course  of  testing,  software  logical  and  procedural 
errors  were  noted  and  SURs  were  generated.  These  SURs  are 
discussed  in  References  1,  2,  3. 

The  three  text  scenarios  were  designed  to  exercise 
different  options  of  the  software: 

Test  Scenario  01  tests  the  ECCM  adaption  software  where 
there  is  a  single  user  group  defined,  with  all  users  and 
circuits  of  the  same  priority  but  with  differing  data  rates. 

Test  Scenario  02  tests  the  ECCM  adaption  software  for 
multiple  user  groups  and  priorities  with  differing  data  rates 
on  the  individual  links. 

The  third  scenario,  the  'NEW  USER  TEST'  scenario  tests  the 
network  performance  software  and  output  generation  software 
without  the  need  for  ECCM  adaption.  In  other  words,  all 
traffic  for  this  scenario  was  designed  to  be  supportable 
without  adapting  the  MBA  or  constraining  the  data  rate.  This 
ability  to  test  the  software  for  continuity  of  output  was 
especially  important  for  the  DNBS  2. 1/3.1  tests  as  Version  2.1 
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Figure  3-1.  Test  Methodology 


did  not  contain  the  ECCM  adaption  software.  Thus,  the  only 
true  comparison  to  be  made  for  this  version  release  (3.1)  was 
through  the  'NEW  USER  TEST'  scenario. 

Details  on  all  three  scenarios  can  be  found  in  Reference  1. 

For  the  adaption  subsystem  runs,  a  tie  breaker  mode  was 
employed.  When  a  traffic  network  is  not  fully  supportable,  the 
breaker  criteria  are  used  to  determine  which  links  should  be 
eliminated,  reduced  in  data  rate,  etc. 

When  traffic  elements  are  adapted  into  the  network  and  two 
links  have  equal  adaption  criteria,  the  adaption  algorithm 
needs  a  mechanism  to  determine  which  data  elements  to  consider 
first.  This  mechanism  is  the  "Data  Rate  Tie  Breaker."  Should 
all  other  adaption  criteria  be  equal,  the  data  rate  requested 
by  the  traffic  elements  is  used  to  determine  which  element 
should  be  selected  ( i . e . ,  High  -  choose  higher  data  rate).  If 
data  rates  are  the  same,  the  final  selection  mechanism  is 
simply  the  sequential  order  of  the  elements  in  the  data  base. 

Each  of  the  two  "Test"  scenarios  was  run  twice;  once  with 
the  tie  breaker  set  to  "High"  and  once  with  the  tie  breaker  set 
to  "Low." 

3.3  TEST  ASSUMPTION 

In  analyzing  the  results  of  the  version  comparison,  it  was 
assumed  that  variations  of  +0.01  dB  were  attributed  to  roundoff 
error.  It  was  further  assumed  that  variations  of  _+0 .  5  dB  were 
acceptable,  given  that  +0.5  dB  is  equivalent  to  a  12  percent 
error  and  -0.5  dB  equivalent  to  an  11  percent  error  (1  -  .89). 

When  the  results  of  the  two  adaptation  cases  were  compared 
(Test  01  and  Test  02),  both  modes  of  the  adaptation  tie  breaker 
were  exercised. 
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When  adaptation  cases  were  compared,  the  total  offered 
(uplink)  load  in  kilobits  per  second  versus  the  supported  load 
was  calculated  and  compared  version  to  version.  In  addition, 
the  total  number  of  links  offered  versus  percent  supported  were 
compared . 

Due  to  large  numbers  of  circuits  present  in  the  "new  user 
test  scenario,"  only  ECCM  circuits  results  were  compared  to 
keep  within  the  projected  effort  for  this  subtask. 

3.4  SUMMARY  OF  RESULTS 


This  section  summarizes  the  results  obtained  for  the  three 
versions,  the  conclusions  drawn,  and  the  recommendations  made 
as  a  result  of  the  overall  test  effort. 

3.4.1  DNPS  Version  3.1  Test  Results 


M/A-COM  completed  Version  3.1  tests  in  January  1986,  and 
detailed  results  of  the  test  effort  can  be  found  in  Reference  1. 
The  baseline  for  comparison  of  test  results  was  DNPS  Version 

2.1. 

Test  Scenario  01  Results 


Test  Scenario  01  included  ECCM  links,  FH  links,  FDMA  links, 
and  a  definition  for  a  jammer.  Critical  circuit  criteria  flags 
were  set  to  their  default  condition,  and  a  single  user  group 
within  this  test  scenario  was  defined  as  having  a  priority  of 
"000002."  Thus,  after  inclusion  of  the  CCC,  RCCC,  and  IET 
links,  all  ECCM  data  circuits  were  given  an  equal  priority  for 
inclusion  in  the  network.  FDMA  links  were  given  varying 
priorities  from  4  through  14  and  were  unconstrained.  Thus, 
under  the  current  version  of  the  software,  FDMA  links  were  not 
expected  to  be  adapted  into  the  network  (i.e.,  they  must  be 
constrained).  Details  of  this  scenario  can  be  found  in 
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Reference  1.  Data  rates  on  the  circuits  within  the  ECCM  links 
were  varied  in  order  to  exercise  the  software.  FDMA  links  were 
allocated  among  Channels  1,  2,  3,  and  4.  Modulation  and  coding 
types  were  also  varied  on  the  links,  and  a  small  number  of  FH 
links  were  also  included  for  completeness.  The  adaption 
criteria  were  based  solely  on  the  circuit  priority. 


Test  Scenario  01  was  used  to  test  DNPS  Version  3.1 
software  for  two  cases:  once  with  the  tie  breaker  set  at 
"High"  and  once  with  the  tie  breaker  set  at  "Low." 


Test  Scenario  01  Analysis 


Test  Scenario  01  included  several  high  data  rate  links 
(i.e.,  greater  than  100  kbps)  with  the  remaining  links  having 
data  rates  of  0.075  kbps  or  1.1  kbps.  Under  the  default  data 
rate  tie  breaker  of  "high,"  many  of  the  links  with  lower  data 
rates  were  not  successfully  adapted.  This  network  configura¬ 
tion  is  consistent  with  the  adaption  criteria  and  default 
adaption  settings.  Tables  3-1  and  3-2  present  results  for  this 
scenario  (Tie  Breaker  "high").  Of  114  elements,  only  29  of  the 
95  ECCM  elements  were  successfully  adapted  into  the  network 
(30.5  percent).  As  expected,  none  of  the  FDMA  traffic  elements 
were  adapted  into  the  network  because  FDMA  links  must  be 
"constrained"  to  be  included  in  the  network.  Overall,  29  of 
114  elements  were  not  adapted  into  the  network,  or  only  25.44 
percent  of  the  total. 


In  terms  of  throughput,  only  1117.5  kbps  of  the  offered 
uplink  3137.775  kbps  was  supported  on  Channel  1,  and  none  of 
the  FDMA  links  were  supported.  This  represents  a  throughput 
reduction  of  64.4  percent  ( 1-car r ied/of fered)  . 

The  scenario  was  run  again  using  the  same  steps  as  docu¬ 
mented  in  Reference  1;  however,  the  tie  breaker  was  set  at 
"low."  In  this  second  run  through  adaption,  the  resulting 


1 


network  configuration  is  again  consistent  with  the  adaption 
criteria  and  tie  breaker  selected.  That  is,  the  adaption 
process  selected  the  lower  data  rate  links  at  tie  breaker 
points,  and  the  resulting  network  included  lower  data  rate 
links  and  rejected  the  unsuppor table  high  data  rate  links. 


Table  3-1.  Version 

3.1,  Tie  Breaker 

"High, " 

Scenario 

ECCM 

FDMA 

TOTAL 

Total  No.  of 

Traffic  Elements 

95 

19 

114 

Total  No.  of 
Elements  Adapted  in 

29 

0 

29 

Offered  Uplink 

Load  (kbps) 

3137.775 

1023.55 

4161.: 

Downlink  Carried 
Load  (kbps) 

1117. 5 

0 

1023. ! 

Table  3-2.  Version 

3.1,  Tie  Breaker 

"Low," 

Scenario  1 

ECCM 

FDMA 

TOTAL 

Total  No.  of 

Traffic  Elements 

95 

19 

114 

Total  No.  of 
Elements  Adapted 

91* 

0 

91* 

Uplink  Offered 

Load  (kbps) 

3137.775 

1203.55 

4161. 

Downlink  Carriers 
Load  (kbps) 

1037.7 

0 

1037. 

*Includes  two  elements  at  0.00  kbps. 

Table  3-2  presents  specific  results  for  this  scenario,  with 
the  tie  breaker  set  at  "low."  Of  a  total  of  114  traffic  ele¬ 
ments,  91  were  adapted  into  the  network  or  79.82  percent.  Of 
the  ECCM  elements,  91  of  95  elements  were  adapted,  or  95.79 
percent.  However,  as  expected,  the  high  data  rate  links  were 
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dropped  in  favor  of  the  low  data  rate  links.  Of  the 
3137.775  kbps  offered  on  Channel  1,  1037.7  kbps  were  supported, 
a  decrease  of  66.93  percent,  and  all  of  the  supported  links 
were  "low"  data  rate  links  (less  than  100  kbps). 

There  was,  however,  one  anomaly  uncovered  during  these 
runs.  Two  ECCM  elements  (ECCM  09  and  ECCM  10)  were  listed  in 
the  ECCM  link  parameter  summary  as  having  an  active  status 
(i.e.,  "On");  however,  their  data  rates  were  listed  as 
0.00  bps.  This  is  evidently  a  software  problem,  perhaps  a 
rounding  error  and  bears  further  investigation.  An  SUR  was 
issued  and  can  be  found  in  Reference  2. 

If  these  elements  are  removed  from  the  statistics,  only  89 
of  95  links  were  adapted,  or  93.68  percent. 

For  the  FDMA  traffic  elements,  none  of  the  19  FDMA  traffic 
elements  were  adapted  as  expected,  based  on  the  adaption 
criteria  established. 

In  addition,  an  improvement  in  processing  time  required 
was  noted  using  the  tie  breaker  set  at  "low."  The  run  times 
are  as  follows:-*- 

•  Data  Rate  Tie  Breaker  "high"  -  36  CPU  minutes 

•  Data  Rate  Tie  Breaker  "low"  -  29  CPU  minutes. 

Note  that  these  run  times  reflect  process  time  spent  in  the  CPU. 
The  times  do  not  include  the  login  time  required  to  perform  all 
tne  required  steps  prior  to  adaption  and  the  running  of  this 
scenario  through  the  Adaption  subsystem. 


iRun  times  also  include  report  generation  and  use  of  other 
subsystems  of  DNPS . 


Test  Scenario  02  Description 


Scenario  02  included  definitions  for  ECCM  links  and  FDMA 
links.  Different  user  groups  were  defined,  and  prioritization 
of  these  groups  varied  from  "000000"  to  "999998."  Adaption 
criteria  were  also  established  based  on  data  rate  constraints, 
geographic  locations,  and  user  classification  (e.g.,  SVGC).2 
Details  of  this  scenario  can  be  found  in  Reference  1.  Link 
definitions  in  the  scenario  provided  traffic  for  channels  1,  2, 
3,  and  4.  Table  4-1  gives  specific  test  steps.  As  with 
Scenario  01,  the  two  "Tie  Breaker"  modes  were  exercised,  and 
results  obtained  using  Version  3.1  of  DNPS  were  analyzed. 

Test  Scenario  02  Analysis 

Test  Scenario  02  was  defined  with  link  data  rates  from  100 
to  1000  kbps.  Using  the  default  settings  of  the  Adaption 
Subsystem  (including  tie  breaker  set  at  "high"),  most  of  the 
links  of  lower  data  rates  were  unsuppor table.  This  is 
consistent  with  the  options  selected  and  with  the  design  of  the 
software.  Table  3-3  summarizes  the  results  obtained  for  Tie 
Breaker  "high"  of  the  143  (ECCM  plus  FDMA)  unconstrained 
traffic  elements.  Forty-two  of  the  ECCM  traffic  elements  were 
adapted  into  the  network  (29.4  percent).  As  expected,  all  were 
ECCM  elements. 

Thus,  of  the  126  ECCM  elements,  only  33.3  percent  could  be 
supported  in  this  scenario.  Out  of  a  total  uplink  offered  load 
of  2283  kbps,  only  1013.875  kbps  was  supported,  a  reduction  of 
55.6  percent.  On  Channel  1,  half  of  the  FDMA  links  were 
supportable . 


2A  valid  user  class  for  this  scenario. 


Tie  Breaker 

"High, " 

Scenario 

ECCM 

FDMA 

TOTAL 

126 

17 

143 

42 

0 

42 

2283.0 

1023.55 

3306. 

1013.875 

0 

1013. 

No.  of  Traffic 
Elements 

Total  No.  of 
Elements  Adapted 

Total  Uplink  Offered 
Load  (kbps) 

Total  Downlink 
Supported  Load  (kbps) 


The  network  that  was  created  using  tie  breaker  set  at 
"low"  was  consistent  with  the  options  selected  (i.e.,  the  links 
of  large  data  rates  could  not  be  supported) .  Table  3-4 
presents  the  detailed  results  of  this  scenario.  Of  the  total 
143  ( ECCM  plus  FDMA)  traffic  elements,  only  89  traffic  elements 
were  adapted.  Of  these  89,  all  were  ECCM  (Channel  1)  traffic 
elements.  Thus,  of  the  126  ECCM  elements,  89  (or  70.6  percent) 
were  adapted.  Of  a  total  uplink  offered  load  of  2283  kbps, 
281.8  kbps  was  supported,  a  reduction  of  87.66  percent.  On 
Channel  1,  almost  all  of  the  high  data  rate  links  were 
unsupported . 

Table  3-4.  Version  3.1,  Tie  Breaker  "Low,"  Scenario  02 


ECCM 

FDMA 

TOTAL 

Total  No.  of 

Traffic  Elements 

126 

17 

143 

Total  No.  of 

Elements  Adapted 

89 

0 

89 

Total  Uplink  Offered 
Load  (kbps) 

2283.0 

1023.55 

3306  . 

Total  Downlink 
Supported  Load  (kbps) 

281.8 

0 

281.8 
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The  run  times  for  this  scenario  were  as  follows:-5 

•  Data  Rate  Tie  Breaker  "high"  -  88  CPU  minutes 

•  Data  Rate  Tie  Breaker  "low"  -  51  CPU  minutes. 

A  significant  improvement  in  processing  was  noted  using  the  tie 
breaker  set  at  "low."  Note  that  these  run  times  reflect 
process  time  spent  in  the  CPU.  The  times  do  not  show  the  login 
time  required  to  perform  all  the  required  steps  prior  to 
adaption  and  running  this  scenario  through  the  Adaption 
subsystem. 

As  in  Test  Scenario  01,  the  adaption  process  in  Test 
Scenario  02  did  not  provide  any  successfully  adapted  FDMA  links 
This  is  consistent  with  the  adaption  criteria  established  in 
the  scenario  definition. 

New  "User-Test"  Scenario  Description 

The  user-test  scenario  provides  for  verification  of  output 
of  different  versions  of  DOSS/DNPS  software.  This  scenario  was 
established  as  a  feasibility  study  of  traffic  in  Channel  1; 
although  the  scenario  contains  definitions  for  links  in  other 
channels,  the  scenario  was  primarily  used  for  the  evaluation  of 
Channel  1  traffic.  Unlike  test  scenario  01  and  test  scenario 
02.  The  new  user  test  scenario  was  chosen  such  that  the 
adaption  subsystem  would  not  be  required  to  develop  a 
supportable  network.  Development  of  the  latter  scenario  was 
necessary  since  Version  2.1  does  not  have  ECCM  adaption 
capabilities  (i.e.,  no  ENAM  as  in  Version  3.1)  and  direct 
comparison  of  results  between  Versions  3.1  and  2.1  would  not  be 
possible  using  test  scenarios  01  and  02. 

3Run  times  also  include  report  generation  and  use  of  other 
subsystems  of  DNPS. 
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Due  to  the  large  number  of  Channel  1  circuits  in  the  new 
user  scenario,  it  was  not  possible  to  analyze  all  links. 

Instead,  22  circuits  were  analyzed  in  detail  along  with  an 
overall  comparison  of  satellite  and  network  parameters  between 
software  versions  (2.1  and  3.1). 

Analysis  of  Results 

In  this  section,  comparative  analyses  are  presented  and 
discrepancies  between  versions  2.1  and  3.1  are  noted.  A  total 
of  three  major  output  report  headings  were  analyzed  in  detail: 
Network  Performance  Subsystems  Network  Performance  Summary,  Net¬ 
work  Performance  Subsystem  Satellite  Analysis  Summary,  and  the 
Network  Performance  Subsystem  Network  Performance  Summary.4 

The  scenario  definition  and  initialization  subsystems  were 
compared  prior  to  detailed  testing  to  ensure  that  each  version 
was  tested  using  the  same  scenario  (i.e.,  terminal,  satellite, 
and  same  user  parameters) .  Detailed  results  of  this  scenario 
can  be  found  in  Appendix  C. 

Network  Performance  Summary 

Results  for  the  Network  Performance  Summary  are  given  in 
Table  3-5  for  "User-Test"  scenario.  For  the  Channel  1  users, 
there  is  no  appreciable  difference  in  Version  3.1  results  over 
Version  2.1  results;  the  Channel  1  backoff^  matches  exactly 
from  version  to  version,  and  the  channel  gain  is  within 
0.02  dB,  well  within  the  round-off  error  expected.  The  same  is 
true  of  the  channel  2  and  5  results;  in  both  cases,  results  are 
identical  between  versions  2.1  and  3.1 


4The  Adaption  subsystem  was  not  exercised  for  these  runs. 
^Backoff  power  (in  dB)  from  saturated  spacecraft  high  power 
amplification. 
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Table  3-5.  Network  Performance  Summary 


PARAMETER 

V2. 1 

V3 .  1 

DELTA* 

Channel  1  Backoff  (dB) 

0.01 

0.01 

0 

2 

3.01 

3.01 

0 

3 

1.55 

1.68 

+  0.13 

4 

1.59 

2.65 

+  1.06 

5 

1.55 

1.55 

0 

6 

1.55 

2.40 

+  0.85 

Channel  1  Gain  (dB) 

105.93 

105.95 

+  0.02 

2 

117.90 

117.90 

0.0 

3 

105. 15 

105.27 

+  .  12 

4 

105.80 

106.28 

+  0.48 

5 

105.65 

105.65 

0 

6 

112.25 

112.73 

+  0.48 

*V3. 1-V2. 1. 

The  results  for  Channel  3  are  not  quite  as  good;  backoff 
is  somewhat  higher  (.13  dB)  as  is  channel  gain  (.12  dB)  for 
Version  3.1  as  compared  to  Version  2.1,  although  still  within 
acceptable  (  +  0.5  dB)  limits. 

Channels  4  and  6  results  show  a  good  deal  of  variation 
from  version  2.1  to  3.1;  1.06  and  0.85  dB  respectively  for 
backoff  and  0.48  dB  each  for  channel  gain. 

One  explanation  for  the  above  differences  is  that  the 
calculation  of  IM  products  was  done  for  Version  2.1  tests,  and 

3-13 


Alii 


II 

i 


^5! 


•$5 


VM 


was  not  done  for  Version  3.1  tests.  This  probably  accounts  for 
the  somewhat  larger  backoffs  present  in  Version  3.1  results. 
Since  the  intermod  products  were  not  present,  and  power  sharing 
was  linear,  a  smaller  fraction  of  total  power  was  necessary  to 
achieve  the  required  link  margins.  (As  the  IM  calculation 
algorithm  may  be  changed  in  the  near  future,  these  runs  were 
not  repeated.) 

Satellite  Analysis  Summary 

The  Satellite  Analysis  Summary  results  are  given  in  Table 
3-6.  As  with  the  Network  Performance  Summary,  channels  1,  2, 
and  5  results  for  Version  3.1  are  all  within  .01  dB  of  Version 
2.1  results.  Again,  due  to  the  addition  of  IM  products 
options,  channels  3,  4,  and  6  satellite  results  in  Version  3.1 
differ  from  Version  2.1  results  in  a  similar  manner  as 
discussed  in  paragraph  5.2.1  on  Network  Performance  Summary. 

Given  the  total  power  present  in  the  downlink  channel,  it 
was  concluded  that  this  is  due  to  user  selection  of  the  option 
to  exclude  IM  power  calculations  in  the  test  of  Version  3.1. 

Link  Performance  Summary 

This  section  presents  version  2.1  and  3.1  link  performance 
summary  results.  Due  to  the  large  number  of  links  in  Channel  1 
(46  SSMA) ,  and  the  fact  that  four  links  are  established  for 
each  SSMA  user  terminal  (RL,  RN,  CCC,  and  USER) ,  all  links  were 
not  analyzed.  Instead,  22  links  were  chosen  at  random  for 
comparison. 

Table  3-7  gives  high  and  low  (greatest  and  smallest) 
deviations  from  Version  2.1  to  3.1. 
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3.4.2  DNPS  Version  3.2  Test  Results 


Beginning  with  Version  3.2  testing,  a  file  comparison 
utility  was  used  to  compare  the  difference  in  values  calculated 
in  the  network  performance  summary  report.  The  reports  were 
analyzed  twice;  once  before  adaption  and  once  after  adaption 
had  been  completed. 

In  addition,  this  utility  was  used  to  verify  the  scenarios 
used  to  determine  that  the  data  migration  utility  software 
performed  its  function  without  corrupting  the  data  base.  Both 
the  system  and  user  data  bases  were  successfully  migrated  to 
the  new  operating  system  without  any  errors  being  detected. 

Test  Scenario  01  Results 


Test  Scenario  01  was  run  again  for  DNPS  versions  3.1  and 
3.2.  No  significant  differences  were  noted  in  the  calculations 
either  before  or  after  adaption,  with  the  exception  of  an 
anomolous  calculation  of  intermodulation  products  in  Channel  4 
[Ref.  2J. 

Adaption  Results 

Test  Scenario  01  included  several  higher  data  rate  links 
(100  kbps)  with  the  links  of  interest  having  data  rates  of  from 
1.1  kbps  to  0.075  kbps.  The  total  uplink  load  offered  to  the 
network  was  3137  kbps  (including  CCC  IET,  and  RCCC  links). 

Under  the  default  tie  breaker  of  "high,"  many  of  the  low 
data  rate  links  were  not  adapted  into  the  network.  This  is 
consistent  with  the  adaptation  criteria  selected.  Table  3-8 
summarizes  the  results  in  terms  of  offered  versus  carried 
uplink  load  (kbps)  and  number  of  downlink  circuits  supported 
for  both  versions  3.1  and  3.2.  The  total  supported  uplink  load 


was  1023.  55  kbps  and  of  the  95  ECCM  traffic  elements,  22  were 
supported  in  both  versions  3.1  and  3.2. 


Table  3-8.  Test 

Scenario  01: 

Tie  Breaker 

High 

V  3 .  1 

V3. 2 

Delta 

l 

Uplink  Offered 

Load  (kbps) 

3137.775 

3137.775 

0 

l 

Uplink  Supported 

Load  (kbps) 

1023.55 

1023.55 

0 

Downlink  Traffic 
Elements  Offered 

95  ECCM 

95  ECCM 

0 

v, 

u 

s 

Downlink  Traffic 
Elements  Supported 

22  ECCM 

22  ECCM 

0 

g 

The  scenario  was  run 

again  with  the  data  rate 

tie  breaker 

set 

to  "low."  Results  are  summarized 

in  Table  3-9. 

The  total 

supported  uplink  load  was 

131.77  kbps 

for  versions 

3 . 1  and  3 . 2 

1 

The 

lower  data  rate  links 

were  selected  over  the  higher  data 

rate 

links,  as  was  expected. 

b 

Table  3-9.  Test 

Scenario  01 

:  Tie  Breaker  Low 

1 

V3. 1 

V3.2 

Delta 

RP 

Uplink  Offered 

fy* 

Load  (kbps) 

3137.775 

3137.775 

0 

r 

Uplink  Supported 

,‘.r, 
i  A 

Load  (kbps) 

137.775 

137.775 

0 

Downlink  Traffic 

£ 

Elements  Offered 

95  ECCM 

95  ECCM 

0 

Downlink  Traffic 

V 

Elements  Supported 

93  ECCM 

93  ECCM 

0 

K 

a 


I 


Based  on  the  results  obtained  in  both  the  "Network  Perform¬ 
ance"  and  "Adaptation"  states,  it  was  concluded  that  the  DNPS 
Version  3.2  was  producing  acceptable  results  for  Scenario  01. 
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Version  3.2  results  closely  agree  with  Version  3.1  results,  and 
no  major  discrepancies  were  noted  in  the  execution  of  the 

software.  The  tie  breaker  high  results  compare  favorably  with 
those  obtained  in  version  2. 1/3.1  testing,  where  1117.5  kbps  of 
throughput  was  achievable.  However,  the  tie  breaker  "low” 
results,  while  supporting  a  similar  number  of  traffic  elements, 
are  off  an  order  of  magnitude  from  the  version  2. 1/3.1 
results.  This  result  requires  further  investigation. 

Test  Scenario  02 


Version  Comparison  Results 

The  FILECOMP  utility  was  again  used  to  compare  results 
between  versions  3.1  and  3.2.  As  with  the  previous  test 
scenario,  comparisons  were  made  in  both  the  network  performance 
state  and  the  adaptation  state.  Differences  are  summarized  in 
Reference  1.  All  results  were  within  acceptable  limits 
(+0.5  dB)  and  most  results  were  within  +0.2  dB. 

Adatation  Results 


This  section  discusses  the  Lesults  of  the  two  adaptative 
runs  made:  tie  breaker  "high"  and  tie  breaker  "low."  As  with 
Test  Scenario  01,  results  are  presented  both  in  terms  of 
offered  versus  carried  load  (uplink)  and  in  terms  of  total 
number  of  traffic  elements  supported.  The  total  load  offered 
to  the  network  for  Test  Scenario  02  was  2283  kbps,  spread  over 
46  links.  These  links  included  8  RTACS  links,  5  SVGC  links, 
and  10  "standard"  EC CM  links  as  well  as  CCC,  IET,  and  RCCC 
links. 


For  the  tie  breaker  "high"  runs  (Table  3-10),  two  ECCM 
links  were  dropped:  ECCM  0901  and  ECCM  1001.  Both  were  1  Mbps 
links,  and  thus  the  total  carried  load  dropped  to  283  kbps  for 


the  ECCM  links, 
supported. 


As  expected/  none  of  the  FDMA  links  were 


Table  3-10.  Tie  Breaker  "High"  Results 


Uplink  Offered 
Load  (kbps) 

Uplink  Carried 
Load  (kbps) 

Downlink  Offered 
ECCM  Traffic 
Elements 

Downlink  Carried 
ECCM  Traffic 
Elements 


V3.1 


2283.0 


283.0 


V3.2 


2283.0 


283.0 


Delta 


(1; 

| 

It?! 


One  possible  explanation  may  lie  in  the  manner  in  which 
traffic  elements  are  sorted  for  adaptation  into  the  network. 

The  sort  software  was  modified  in  this  latest  version,  and 
traffic  elements  were  presented  for  adaptation  into  the  network 
in  a  different  order  from  version  2. 1/3.1  testing.  Because  the 
adaptation  order  changed,  the  adaptation  results  may  have 
changed.  Another  possible  (although  unlikely)  explanation  may 
be  in  the  way  that  FDMA  uses  are  specified  in  the  scenario. 

For  the  tie  breaker  "low"  runs  (Table  3-11) ,  the  same  two 
links  were  dropped  in  both  versions  3.1  and  3.2. 


These  results  are  somewhat  unexpected.  It  is  expected 
that  the  tie  breaker  high  runs  to  produce  results  which  favor 
the  high  data  rate  links.  A  further  check  of  the  Version  3.1 
results,  which  were  obtained  in  December  (V2. 1/3.1;  Reference 
1) ,  shows  a  completely  differently  result  (Table  3-12). 
Resolution  of  this  problem  requires  further  investigation.  An 
SUR  was  issued  for  this  anomolie. 
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Table  3-11.  Tie  Breaker  "Low"  Results 


V3.1 

V3 . 2 

Delta 

Uplink  Offered 

Load  (kbps) 

2283.0 

2283.0 

0 

Uplink  Carried 

Load  (kbps) 

283.0 

283.0 

0 

Downlink  Offered 

ECCM  Traffic 

Elements 

126 

126 

0 

Downlink  Carried 

ECCM  Traffic 

Elements 

124 

124 

0 

Table  3-12. 

Version 

2. 1/3.1  Results 

Tie  "Hiqh" 

Tie  "Low 

Total  ECCM  Traffic  Elements 

126 

126 

Total  Supported  ECCM 

Elements 

29 

91 

Conclusions 

For  the  scenarios  tested,  the  DNPS  software  produced 
consistent  results  between  versions  3.1  and  3.2;  however,  the 
one  discrepancy  mentioned  above  requires  further  investigation. 
In  addition,  the  results  for  the  tie  breaker  "low"  are  compa¬ 
rable  to  those  obtained  in  Version  2. 1/3.1  testing,  where  a 
total  throughput  of  281.8  kbps  was  observed  for  the  ECCM 
(Channel  1)  circuits. 

User  Test  Scenario 


The  user  test  scenario  was  used  to  verify  the  satellite 
analysis,  allocation,  and  network  performance  subsystems  of 
DNPS.  This  scenario  was  developed  by  DCEC  as  a  feasibility 


study  for  Channel  1  traffic.  Because  of  the  large  number  of 
links  present,  only  the  ECCM  traffic  was  analyzed  (as  in 
Reference  1) . 

Scenario  Description 

The  user  test  scenario  consists  of  46  ECCM  links  and  157 
FDMA  links  that  use  100  terminals.  In  addition,  the  scenario 
has  7  jammers  and  2  FH  links.  The  satellite  used  for  the 
defined  network  was  the  Atlantic  DSCS  III  (IRON  6451).  This 
scenario  was  constructed  to  avoid  adaptation.  A  detailed 
description  can  be  found  in  Reference  1. 

Version  Comparison  Results 

The  differences  between  Version  3.1  and  Version  3.2  of 
DNPS  follow.  Note  that  all  values  listed  are  relative  to 
COSS/DNPS  Version  3.2. 

•  Network  Performance  Summary 

No  differences  were  noted  in  any  calculation  between 
the  two  versions  of  the  software. 

•  Link  Performance  Summary 


All  values  listed  are  relative  to  Version  3.2  of  DNPS 
High,  low,  and  average  deviations  are  given  in  dB. 


m 


I 

.11  , 
IV)1 
i\  i 
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Link  Type 


CCC  Average 
IET  Average 
RL1/RN1  High 
RL1/RN1  Low 
RL1/RN1  Average 
ECCM  High 
ECCM  Low 
ECCM  Average 


Terminal  Delta  (dB) 


-.16 


-.16 
+  .83 
-1.53 
-.2858 
+  .83 
-1.53 
-.6384 


•  Terminal/Jammer  Directive  Gain  Summar 


No  differences  were  noted  (in  any  calculation)  between 
versions  of  the  software. 

Satellite  Analysis  Summar 


No  differences  were  noted  (in  any  calculation)  between 
versions  of  the  software. 

Based  on  the  above  results,  the  new  user  test  scenario  was 
verified  in  Version  3.2  of  the  DNPS.  Although  the  terminal 
Delta  power  deviation  was  somewhat  high  in  two  cases  (-1.53  dB) 
the  overall  performance  of  the  network  was  verified  to  be 
within  the  tolerances  discussed.  It  is  not  clear  why  the 
terminal  data  power  measurements  were  off  by  such  a  large 
amount  (1.53  dB) .  This  problem  needs  further  investigaton, 
because  it  was  also  observed  (but  not  resolved)  during  Version 
2. 1/3.1  testing. 

3.4.3  DNPS  Version  4.0 

For  this  particular  release,  only  one  "engineering"  change 
was  made  to  the  software:  the  major  emphasis  of  this  release 
was  the  modification  of  software  report  generator  logic  and 
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run-time  logic.  It  was  agreed  that  it  would  not  be  necessary 
to  perform  a  complete  version  comparison  test  (as  was  done  with 
previous  releases) . 


Instead,  the  system  software  was  checked  for  logical 
errors,  and  results  were  checked  in  an  engineering  sense  only 
for  these  modules  affected  by  the  recent  change  (i.e.,  the  PN 
Code  Rate  Change) . 

SURs  were  generated  as  appropriate  and  can  be  found  in 
Appendix  A  of  Reference  3. 

3.4.3. 1  Summary  of  Results 

This  version  of  software  performed  as  expected  utilizing 
established  scenario  files  used  in  past  testing  efforts.  The 
significant  change  in  this  version  (at  the  DCEC)  was  a  new  VAX 
VMS  operating  system,  an  11/730  computer  to  replace  the  PDP-11, 
and  new  display  devices  (i.e.,  Tektronix  4107/4125  printer  and 
plotters) .  There  were  no  gross  errors  noted  in  this  release  of 
the  software  despite  the  major  changes  in  hardware  and  system 
software . 

Software  Logic 

I  During  the  testing  effort,  10  SURs  were  subsequently 

generated  and  submitted  (Appendix  A  of  Reference  3) .  The  most 
significant  of  these  describe  a  change  that  resulted  when  a 
user  aborts  adaption  and  enters  the  Network  Performance 
!  Subsystem.  If  the  user  enters  the  "Margin  Leveling"  subsystem, 

*  the  software  does  not  display  the  expected  menu  and  seems  to  be 

executing  code.  While  this  in  itself  is  not  significant,  any 
documented  changes  to  the  software  should  not  have  created  this 
.  anomaly.  Regression  testing  of  Version  3.2  shows  that  this 

I  anomaly  is  unique  to  Version  4.0. 


I 
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Another  anomaly  of  the  software  present  in  both  versions 
3.2  and  4.0  dealt  with  the  Adaption  subsystem.  When  the  user 
aborts  an  adaption  run  and  returns  to  the  top  level  of  DNPS , 
the  system  state  is  "Adaption"  when  it  should  be  "Network 
Performance."  When  the  user  returns  to  the  top-level  menu  of 
DNPS,  through  normal  termination,  the  adaption  software  has 
tried  to  include  all  links  into  the  network,  the  system  state 
is  set  to  "Network  Performance"  when  it  should  be  "Adaption." 
Logically,  the  terminology  of  the  system  states  seems  to  be 
reversed  for  the  cases  noted. 

Display  Algorithms 


Because  of  Tempest  noncompliance  of  the  4125  display 
device  (at  the  time  of  testing  at  DCEC) ,  output  to  this  device 
could  not  be  fully  tested.  Utilizing  the  DCMTEST .  EXE  and  the 
4014  Tektronix  softcopy  display  device,  most  aspects  of  the 
display  algorithms  were  tested.  Certain  anomalies  existed  in 
the  automatic  display  of  the  Adaption  Ranking  Report.  While 
the  user  could  automatically  display  the  report  at  a  predefined 
step  in  the  creation  of  the  network,  only  page  one  (of  a 
multipage  report)  was  being  displayed.  This  limitation  of  this 
change  in  the  software  severely  restricts  the  usefulness  of  the 
change. 

Engineering  Changes 

The  only  engineering  change  made  to  this  version  involved 
the  calculation  of  the  bandwidth  of  an  ECCM  Link  (implementa¬ 
tion  of  SUR457).  In  Version  4.0  the  ECCM  link  bandwidth  was 
set  to  be  twice  the  chip  rate.  Initial  results  of  this  change 
showed  an  error  in  the  Network  Performance  and  Link  Performance 
Reports:  link  origins,  which  were  being  met  in  Version  3.2, 

were  not  easily  met  in  Version  4.0  for  the  same  scenarios. 


The  resulting  investigation  of  these  anomalies  by  Stanford 
Telecommunications  Inc.  (STI)  showed  that  the  software  was  not 
correctly  modified  for  this  change.  A  follow-up  (emergency 
patch)  release  was  distributed  and  further  testing  showed  the 
corrected  implementation  to  perform  as  intended.  It  has  been 
subsequently  decided  to  remove  this  change  and  delay  its 
implementation  to  a  future  release. 

3.5  RECOMMENDATIONS  AND  CONCLUSIONS 

3.5.1  Conclusions 

In  general,  the  DNPS  software  has  produced  consistent 
results  from  version  to  version  in  terms  of  power  levels  and 
margins  in  the  Network  Performance/Allocation  Subsystems. 

However,  a  number  of  anomalous  conditions  were  noted  in 
the  Adaption  subsystem,  particularly  in  the  Version  3. 1/3. 2 
test  results.  These  anomalous  conditions  are  described  in 
References  1,  2,  and  3,  and  should  be  investigated  and 
accounted  for  in  order  to  maintain  user  confidence  in  the 
software . 

3.5.2  Recommendations 

Automated  Testing 

Because  DOSS/DNPS  is  a  network-driven  software  package,  it 
is  possible  to  automate  the  testing  effort.  This  automation 
could  be  as  simple  as  using  data  files  to  emulate  the  user 
input  that  would  be  transmitted  (via  DECNET)  to  DOSS/DNPS. 
Additional  methods  exist  to  automate  this  process,  such  as 
modifying  the  local  networking  node  emulator  (DCMTEST.EXE). 
These  modifications  could  include  the  following: 
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1. 


installed  in  DCMTEST.EXE  to  provide  a  method  to  exit 
DOSS/DNPS.  This  method  would  also  allow  an  orderly  o 

reentry  into  DOSS/DNPS. 

2.  User  Emulation.  Data  files  could  be  used  to  emulate 
user  interaction  with  DOSS/DNPS. 

3.  Interactive  File  Examination.  DOSS/DNPS  reports  could 
be  reviewed  (excluding  plotter  output)  interactively 
at  the  VT100  terminal. 

Additional  methods  of  automated  testing  should  be  explored. 

It  is  recommended  that  a  set  of  scenarios  be  developed 
which  are  specifically  designed  to  test  the  new/improved 
features  of  the  release  in  question.  For  example,  a  set  of 
Version  4.0  scenarios  might  have  been  developed  that  tested  the 
PN  code  rate  versus  bandwidth  calculations  during  the  SUR 
integration  phase  and  the  beta  test  phase. 

In  this  manner,  problems  with  the  software  can  be  surfaced 
and  corrected  before  version  release  testing. 

Ideally,  these  test  procedures  should  be  specified  before 
any  software  is  modified  and  should  be  developed  independently 
of  the  new  software.  That  is,  a  test  or  tests  should  be 
devised  that  evaluate  the  new  software  in  a  general  sense,  and 
in  both  a  stand-alone  (module)  and  fully  integrated  manner. 

The  file  comparison  utility  FILECOMP.EXE  could  be  used  to 
aid  in  automated  verification.  This  could  be  accomplished  by 
establishing  formalized  procedures  concerning  data  generated 
and  the  programs  used.  Additional  methods  of  verification 
automation  should  be  explored. 
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Additional  Sceanrios 

It  is  recommended  that  two  additional  scenarios  be 
established.  These  are  as  follows: 


1.  Minimal  Configuration  Scenario.  A  scenario  should  be 
established  that  meets  the  minimum  requirements  for  a 
user-defined  scenario.  This  scenario  would  test  the 
software  for  its  ability  to  meet  documented 
requirements  for  such  scenario  definitions.  In 
addition,  it  would  create  an  additional  criterion  for 
software  testing  and  validation  between  versions  of 
software . 


2.  Maximum  Configuration  Scenario.  A  scenario  should  be 
established  that  tests  the  software's  ability  to 
detect  the  maximum  limits  in  scenario  definitions. 
This  scenario  would  also  verify  documentation  of  the 
software  for  such  limits.  In  addition,  this  scenario 
would  also  benchmark  the  software  in  a  "worst  case" 
(maximum  data  definition)  test. 


Software  Runtime  Anal' 


Methods  to  analyze  the  software  using  noninterfering  means 
should  be  examined.  This  would  involve  the  creation  of  a  body 
of  software  that  would  accumulate  software  performance 
statistics.  The  accumulated  data  would  aid  DCA/DCEC  personnel 
in  making  decisions  concerning  software  modifications. 


Man-Machine  Interface  (MMI)  Baseline 


When  a  module  (i.e.. 


a  subroutine)  is  modified,  it  should 
be  tested  (and  the  testing  procedures  documented)  prior  to 
integration  into  the  software  system. 

Module  Testing 

It  is  recommended  that  the  software  be  tested  by  module 
(subroutine).  This  involves  "desk  checking"  a  specific  module 
and  then  testing  the  specific  module  for  integrity. 

Module  Extraction 


It  is  recommended  that  some  of  the  modules  of  DOSS/DNPS  by 
used  in  other  stand-alone  programs.  An  example  of  this  would 
be  the  Resource  Allocation  Software  (RAS)  COTRAN  software. 

This  software  package  calculates  the  Azimuth  and  Elevation 
angel,  the  satellite  antenna,  based  on  the  earth  terminal 
locations.  It  is  possible  to  use  this  software  package  to 
calculate  the  latitude  and  longitude  of  a  terminal  based  on  the 
azimuth/elevation  (or  azimuth  and  elevation  based  on  latitude 
and  longitude).  Module  extraction  would  realize  programs  to 
support  task-specific  problems  using  existing  software.  In 
addition,  this  method  provides  a  means  to  test  specific  modules 
of  DOSS/DNPS. 


CHAPTER  4 

SUBTASK  C:  MULTIPLE  BEAM  ANTENNA  ANALYSIS 


This  subtask  was  extended  prior  analyses  to  develop  methods 
to  improve  the  Multiple  Beam  Receive  Antenna  (MBR)  Resource 
Allocator  Algorithm  for  the  DSCS  III  spacecraft.  The  proposed 
algorithm  used  a  gradient  technique  to  find  the  optimum  beam- 
weights  based  on  a  functional  minimization  of  the  constrained 
Least  Mean  Square  (LMS)  error  between  desired  and  actual  antenna 
gains . 

4.1  DESCRIPTION  OF  THE  MBR  ALGORITHM 


This  section  discusses  a  constrained  LMS  algorithm  to 
select  beam  weights  for  an  MBR  antenna.  The  antenna  will 
synthesize  a  desired  antenna  gain  pattern  that  is  specified  by 
the  magnitude  response. 


4.1.1  Description  of  the  Solution  Approach 


It  is  useful  to  characterize  the  total  response  of  an 
antenna  both  by  magnitude  and  by  phase  responses  over  the  field 
of  view  (FOV).  However,  since  only  directive  gain  is  specified 
for  each  earth  terminal,  only  the  magnitude  response  is 
considered  here. 

Least  Mean  Square  Error  Criterion 

The  solution  approach  is  an  LMS  fit  to  the  desired 
directive  gains  of  the  MBR  antenna.  Such  a  solution  has  the 
f  orm : 
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where  dm  is  the  desired;  complex  voltage  gain;  gm  is  the 
resultant  complex  voltage  gain;  and  fc>m  is  a  positive  real 
constant  indicating  the  relative  importance  of  each  point. 
Rewriting  equation  (4-1)  in  vector  form,  the  expression  becomes 

e2  =  (|  D  |  -  !  G  I  )  TB  (ID!  -  |  G I  )  ,  (4-2 

where  D  is  the  Mxl  desired;  complex  voltage  gain  vector;  G  is 
the  Mxl  resultant,  complex  voltage  gain  vector;  and  B  is  an  MxM 
positive  real  diagonal  weighting  matrix.  The  symbol  T  denotes 
the  transpose  of  a  vector  or  matrix,  and  M  is  the  number  of 
specified  terminal  locations. 

The  resultant  gain  G  is  a  function  of  the  ambient  pattern 
of  the  antenna  and  the  beam  weights.  The  ambient  antenna 
pattern  is  modelled  using  the  singlet  antenna  data,  which  gives 
the  gain  for  each  of  the  antenna  elements  at  specified 
locations  on  the  earth's  surface.  A  singlet  data  matrix  may  be 
constructed  for  different  areas  of  interest  on  the  earth's 
surface,  and  the  matrix  has  the  form: 

A  =  [x  +  y  ] 

m,n  Jm,nm,n 

where  m  =  az imu th/e  leva t ion  coordinate  index;  m 
n  =  singlet  beam  index;  n  =  1,  2,  ...,  N. 

That  is,  each  of  the  M  rows  of  A  correspond  to  a  specific 
azimuth/elevation  coordinate  point  within  the  area  of  interest, 
and  each  of  the  N  columns  correspond  to  a  particular  singlet 
beam.  For  DSCS  III  spacecraft,  the  number  of  singlet  beams,  N, 
is  61,  and  M  may  vary  from  one  point  to  full  coverage  of  8281 
points*. 

♦Full  coverage  consists  of  +9°  azimuth  and  elevation,  with 
0.2o  granularity,  fromthe  subsatellite  point. 
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The  resultant  gain  is  given  by  the  vector  expression: 


G  =  A  W  (4-4) 

where  G  is  the  Mxl  resultant,  complex  voltage  gain  vector;  A  is 
a  MxN  complex  matrix  of  singlet  data;  and  W  is  Nxl  the  complex 
beam  weight  vector. 

For  typical  scenarios,  the  gains  at  terminal  locations  are 
specified  in  decibels,  not  volts.  To  convert  the  resultant 
voltage  gain  to  directive  gain,  the  following  expression  is 
used : 


(G)  dB  =  20  log1Q  [I  G|  ]  (4-5) 

where  G  is  the  complex  voltage  gain  defined  in  equation  (4-4). 

Substituting  equation  (4-4)  in  equation  (4-2),  the 
expression  becomes: 

e2=(IDI-IAWI)TB(|D|-|AW|).  (4-6) 

The  problem  is  to  find  the  beam  weight  vector,  W,  that 
minimizes  e2.  There  are  several  computer  packages,  such  as 
the  International  Mathematics  and  Statistical  Library  (IMSL), 
containing  gradient  optimization  routines  to  perform  the 
minimization.  The  IMSL  package  uses  a  gradient  technique, 
called  the  Davidon-Fletcher-Powell  (DFP)  algorithm  to 
functional  minimization.  The  DFP  algorithm  uses  the  following 
iterative  formula  to  perform  the  minimization. 


— k  +  1  ~  iik  ~  ak  Hk  2k 

where 

+  ^  =  the  new  value  of  the  vector  W 

=  the  previous  value  of  the  vector  W 
au  =  constant 


a  matrix 


Hk  - 

2-k  =  the  gradient  of  the  function  to  be  minimize. 

The  program  performs  iterations  until  some  acceptance 
criterion  is  met;  e.g.,  a  certain  number  of  iterations  are 
performed  or  the  difference  between  new  and  old  values  is  less 
than  a  given  tolerance. 


Constrained  LMS  Criterion 


Although  the  LMS  method  may  be  used  to  find  a  solution, 
there  is  an  additional  constraint  on  the  solution  vector:  its 
norm  must  equal  one. 


II  W  II  =  1 , 


(4-7) 


or  , 


Wfc  W  =  1.  (4-8) 

This  constraint  arises  from  the  fact  that  the  antenna  of 
interest  is  a  passive  device,  and  thus,  its  gain  must  be  less 
than  or  equal  to  unity. 

A  standard  way  to  include  a  constraint  in  the  solution  is 
to  compose  a  cost  function  of  not  only  the  LMS  cost  function 
e^  ,  but  also  a  penalty  function,  P,  to  address  the 
constraint.  Such  a  cost  function  has  the  form: 

C  =  e2  +  kP.  (4-9) 

The  k  is  a  weighting  constant  for  the  penalty  function. 

In  this  case,  the  penalty  function  may  be  expressed  as  the 
squared  difference  between  the  actual  norm  of  the  beam  weight 


vector  and  the  required  norm.  The  new  cost  function  is  given 
by: 

C  =  e2  +  k  [1  -  u  W  II  ]  2  (4-10) 

The  same  IMSL  optimization  routine  may  be  used  as  with  the 
unconstrained  case  to  find  the  beam  weight  vector,  W,  that 
minimizes  the  cost  function  given  by  equation  (4-10). 


Pattern  Control 


the  Wei< 


Matrix 


One  of  the  features  of  the  proposed  algorithm  is  that  it 
allows  different  weighting,  or  emphasis,  via  the  B-matrix  of 
equation  (4-6).  In  equation  (4-6),  the  B  matrix  contains  the 
information  about  weighting  for  each  terminal.  Weighting  may 
be  applied  in  different  ways.  User  locations  in  a  network  or 
interferer  locations  may  have  different  weight  values  assigned, 
based  on  their  relative  importance.  The  weight  elements  of  the 
B  matrix  may  also  be  used  to  emphasize  a  particular  terminal  or 
set  of  terminals  to  increase  the  antenna  discrimination  in  a 
particular  region  in  the  FOV.  This  is  especially  useful  in 
scenarios  where  desired  and  interfering  terminals  are  in  close 
proximity.  Thus,  based  upon  the  selection  of  different 
weighting  (or  emphasis)  matrices  Blf  b2,  .  ..,  the  LMS 
algorithm  will  produce  different  antenna  beam  weight  vectors 

"v^l  /  W  2 ,  ...  . 


4.2  TEST  SCENARIOS 


Although  an  infinite  variety  of  test  scenarios  can  be  used 
to  demonstrate  the  performance  of  an  MBA  algorithm,  a  single, 
relatively  simple,  generic  scenario  was  used  to  demonstrate  the 
performance  for  critical  applications  and  to  show  the  limiting 
performance  cases.  All  of  the  examples  considered  in  this 
report  were  derived  from  the  same  basic  scenaro  with  terminal 
locations  given  in  Figure  4-1.  The  locations  of  interferers 
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nario 


are  not  shown  because  these  locations  depend  upon  the  specific 
example.  Also,  for  simplicity,  the  directive  gain  to  all  the 
desired  terminals  were  chosen  to  be  equal,  but  the  gain  varied 
from  one  example  to  another.  The  gain  was  arbitrarily  chosen 
to  be  either  20  or  25  dBi  --  typical  uplink  gain  values  for 
DSCS  users.  Likewise,  the  required  discrimination  between  the 
desired  terminals  and  interferers  depends  upon  the  particular 
example  and  is  specified  to  be  either  40  or  50  dB.  The  values 
of  the  required  gain  and  discrimination  are  not  based  on  actual 
requirements,  but  are  intended  to  reflect  typical  scenarios  and 
the  capabilities  of  the  MBR  antenna. 

4.3  INTERFERER  LOCATION 

The  first  set  of  examples  demonstrates  the  effect  of 
interferer  location  on  the  shape  of  the  null.  To  perform  the 
experiment,  the  basic  scenario  (Figure  4-1)  was  used  with 
20-dBi  direction  gains.  A  single  interferer  with  a  desired 
gain  of  -20  dBi  was  moved  from  (0,0)  to  (1,1)  to  (2,2)  in  the 
FOV.  These  locations  correspond  to  angular  distances  of 
3.5°,  2.1°,  and  0.7°,  and  1.4,  0.8,  and  0.3  beamwidths, 
respectively,  from  the  nearest  desired  terminals.  For  each 
location,  the  directive  gain  was  measured  at  points  near  the 
null,  and  the  resultant  gain  profiles  are  plotted  in  Figure 
4-2.  The  plot  shows  the  gain  profile  of  the  null  around  each 
interferer.  The  horizontal  axis  is  the  angular  distance  from 
the  interferer  in  degrees.  (Positive  values  denote  distances 
from  the  null  toward  desired  terminals;  negative  ones, 
distances  from  the  null  away  from  desired  terminals.)  The 
vertical  axis  represents  the  directive  gain  in  decibels. 
Although  the  shapes  of  the  respective  profiles  are  different, 
the  cases  where  the  interferer  is  located  at  (0,0)  and  (1,1) 
achieved  the  desired  40-dB  average  discrimination.  From  Figure 
4-2  it  is  noted  that  when  the  inteferer  is  furthest  away,  the 
pattern  has  a  much  broader  null.  While  the  discrimination  is 
approximately  30  dB  in  1°  with  user-inter ferer  separation 
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a  •=■?  s°  /  it  is  about  38  dB  in  1°  with  0  .=2  l°»  The 
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reduction  in  achievable  discrimination,  which  is  indicated  as  j 

the  user-inter ferer  separation  is  reduced,  shows  the  resolution 
limitation  of  the  given  MBR  antenna  aperture.  With  ®ui=0.7, 
the  desired  discrimination  was  not  achieved;  the  overall  ; 

discrimination  was  only  about  20  dB/°.  However,  the  desired  ! 

directive  gain  of  20  dBi  was  achieved  at  0.85  degrees  from  the 
null,  closer  to  the  null  than  the  other  two  cases  with  greater  [ 

0u^.  In  each  of  these  cases,  the  algorithm  achieved  the 

desired  user  gains,  but  to  do  so  as  0U^  decreased,  the  ! 

algorithm  sacrificed  null  depth  and  discrimination. 

4.4  SPECIFYING  A  NULL  REGION 

The  previous  cases  all  specify  a  single  point  as  the 
interferer  location.  A  more  desirable  pattern,  however,  would 
be  one  in  which  the  null  is  broader  to  account  for  open-loop 
pointing  errors  mentioned  in  Section  4.1.  To  give  a  broader 
null,  a  region  of  null  points  can  be  specified.  This  is  the 
purpose  of  the  next  set  of  experiments. 

These  experiments  focus  on  the  scenario  with  a  single 
interferer  at  (2,2)  (an  angular  separation  of  0.7°),  and  they 
examine  the  effect  that  specifying  a  null  region  has  on  gain 
pattern  shape  and  discrimination.  The  scenario  of  Figure  4-1 
was  used  with  a  single  interferer,  a  (2,2)  (an  angular 
separation  of  =  0.7°).  The  directive  gain  of  the  desired 
terminals  was  chosen  to  be  20  dBi  with  a  point  null  of  -20  dBi. 

Two  examples  were  considered:  one  with  a  single  point  null  and 
another  with  a  null  region.  The  null  region  consists  of  all 
the  points  adjacent  to  the  interferer  location  and  is  shown  in 
Figure  4-3.  The  effect  of  specifying  a  region,  rather  than  a 
single  point,  on  the  gain  profile  is  shown  in  Figure  4-4. 

Specifying  a  null  region  created  a  deeper  null  and  provided 
greater  average  discrimination  between  the  desired  terminals 
and  the  interferer.  To  find  the  average  discrimination,  the 
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Azimuth  in  Degrees 

Figure  4-3.  Null  Region  Used  with  Experiments 


average  difference  in  gain  (in  decibels)  between  each  user 
location,  and  the  interferer  was  computed  as  follows: 

<aoU-  |  KGVae  -  ■ 

where  AG  =  the  average  discrimination 

n  =  the  number  of  user  terminals  (20) 

=  the  resultant  voltage  gain  at  the  k-th  user 
location 

G ^  =  the  resultant  voltage  gain  at  the  interferer 

location 

While  the  average  discrimination  with  a  single-point  null 
was  17.8  dB,  it  was  27.4  dB  with  the  null  region  of  Figure 
4-3.  The  single-point  case  had  the  advantage  of  achieving  the 
desired  gain  at  a  smaller  distance  from  the  interferer.  The 
null-region  achieved  the  desired  20-dBi  gain  at  a  distance 
greater  than  1°,  whereas  the  single-point  achieved  20  dBi  in 
less  than  0.85°.  Therefore,  specifying  a  null  region 
provides  a  deeper  null  and  greater  overall  discrimination  than 
a  single  null  point. 

4.5  WEIGHTING  OF  TERMINAL  AND  NULL  LOCATIONS 

All  previous  examples  used  an  equal  weighting  [B  = 
Identify  Matrix  in  equation  (2-6)]  for  all  terminal  and  null 
locations.  The  next  set  of  experiments  examined  the  effect  of 
weighting  on  null  shape.  The  experiments  used  a  desired 
directive  gain  of  20  dBi  for  terminals,  -20  dBi  gain  for  the 
interferer,  and  a  single-point  null.  Unless  otherwise 
specified  the  nominal  weighting  of  each  location  is  unity. 

Three  weighting  schemes  were  considered  in  the 
experiment.  The  first  scheme  was  an  equal  weighting  for  all 
locations,  the  second  scheme  weighted  the  interferer  location 
with  a  factor  of  10,  and  the  third  example  weighted  the 
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interferer  with  a  factor  of  100.  Gain  profile  curves  for  the 
three  different  weighting  schemes  are  plotted  in  Figure  4-5. 
Although  there  is  little  difference  among  the  three  curves 
beyond  0.3°  from  the  interferer,  the  null  was  clearly  deeper 
with  increased  weighting. 

Figure  4-5  shows  only  the  gain  near  the  null;  it  does  not 
show  how  the  overall  difference  between  the  user  and  the 
interferer  gains  was  affected.  Table  4-1  presents  the  values 
of  the  average  discrimination  for  each  of  the  weighting 
schemes,  and  it  shows  that  the  average  discrimination  increased 
as  the  weighting  increased.  The  predominant  effect  of 
weighting  the  interferer  location  was  to  increase  the  null 
depth  without  changing  the  directive  gain  to  nearby  locations. 
To  determine  whether  the  increased  null  depth  was  achieved  by 
lowering  the  average  gain  to  the  desired  terminals,  the  average 
gains  were  also  computed.  These  results  are  also  presented  in 
Table  4-1,  and  there  was  no  significant  difference  among  the 
three  cases.  Therefore,  the  depth  of  the  null  did  not  affect 
the  average  gain  to  the  desired  terminals. 

Table  4-1.  Average  Discrimination  Versus 
Interferer  Null  Weighting 


Interferer 

Weighting 

Average 

Discrimination 

(dB) 

Interferer 

Gain 

(dB) 

Average 
Terminal  Gain 
(dB) 

1 

17.9 

1.9 

19.9 

10 

32.5 

-12.8 

19.7 

100 

39.0 

-19.2 

19.8 

Comparing  the  effect  of  weighting  a  single  interferer 
location  and  using  a  null  region  (of  multiple  inter ferers)  ,  the 
former  provided  greater  null  depth  and  more  discrimination. 


While  both  methods  may  be  used  to  increase  null  depth,  a  null 
region  tends  to  pull  down  the  gains  beyond  0.3°,  whereas 
weighting  does  not.  That  is,  use  of  nulling  regions  broadens 
the  null  width  at  the  expense  of  a  gain  reduction  to  the  user 
locations . 

4.6  COMBINED  EFFECTS 

To  this  point,  the  discussion  has  focused  on  how  a  null 
region  and  weighting  individually  affect  the  shape  of  the 
null.  This  section  considers  the  effect  if  both  techniques  are 
used  simultaneously. 


I 


i 

i 


These  experiments  use  the  basic  scenario  with  a  single 
interferer  at  (2,2).  The  same  null  region  shown  in  Figure  4-3 
is  specified  with  a  desired  directive  gain  of  -25  dBi,  and  the 
gain  to  users  in  25  dBi.  All  locations  had  unity  weighting 
except  the  interferer  location  at  (2,2),  which  was  assigned 
weighting  factors  of  1,  10,  and  100.  Gain  profiles  for  the 
three  different  weighting  schemes  are  plotted  in  Figure  4-6. 
Although  there  is  little  difference  among  the  three  beyond 
0.3°  from  the  interferer  location,  the  depth  of  the  null  was 
increased  with  increased  weighting.  Table  4-2  presents  the 
values  of  the  average  discrimination  for  each  of  the  schemes 
and  shows  that  the  value  increased  as  the  weighting  increased. 
The  predominant  effect  of  weighting  the  interferer  location  was 
to  increase  the  null  depth  without  changing  the  directive  gain 
to  locations  beyond  0.3°.  To  determine  whether  the  increased 
null  depth  was  achieved  by  lowering  the  average  gain  to  the 
desired  terminals,  the  average  gains  were  computed.  The 
average  directive  gain  to  users  are  also  presented  in  Table 
4-2.  There  is  no  significant  difference  in  average  gain  noted 
among  the  three  cases.  Therefore,  an  increase  in  null  depth 
did  not  sacrifice  gain  to  the  desired  terminals. 
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Angular  Separation  in  Degrees 

Effect  of  Weighting  and  a  Null  Region  on  Null 


Table  4-2.  Average  Discrimination  with  a  Null 
Region  and  Different  Weighting 


Interferer 

Weighting 

Average 

Discr iminat ion 
(dB) 

Interferer 

Gain 

(dB) 

Average 
Terminal  Gain 
(dB) 

1 

25.  2 

-3.5 

21.7 

10 

31.7 

-  9.8 

21.9 

100 

42.9 

-21.1 

21.8 

4.7  COMPARISON  NULLING  CRITERIA 

The  experimental  results  discussed  in  previous  sections 
have  shown  that  by  increasing  the  relative  importance 
(weighting)  of  selected  locations  to  achieve  required  directive 
gains,  and  by  adding  specified  gain  location  to  extend  the 
desired  gain  region,  different  resultant  gain  patterns  and  null 
region  shapes  can  be  produced.  The  characteristics  of  these 
different  pattern  may  be  exploited  to  meet  specific  scenario 
requirements . 

This  section  compares  three  patterns  produced  for  a 
particular  scenario,  and  identifies  the  characteristics  and 
trade-offs  associated  with  each.  Three  cases  with  the  scenario 
of  Figure  4-1  and  a  single  interferer  at  (2,2)  (an  angular 
separation  of  =  0.7°)  are  considered. 

1.  An  unweighted  interferer  specified  by  a  single-null 
point,  40-dB  desired  discrimination,  and  20-dBi 
desired  terminal  gain. 

2.  A  weighted  (weight=10)  interferer  specified  by  a 
null-region,  40-dB  desired  discrimination,  and  20-dBi 
desired  terminal  gain. 

3.  A  weighted  (weight=100)  interferer  specified  by  a 
null-region,  50-dB  desired  discrimination,  and  25-dBi 
desired  terminal  gain. 
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The  gain  profiles  of  these  three  cases,  each  involving  a 
single  interferer  at  (2,2),  are  plotted  in  Figure  4-7. 

Although  these  three  cases  have  nearly  the  same  gain  at  1° 
from  the  interferer,  the  shapes  of  the  nulls  generated  are 
quite  different.  If  it  is  more  important  to  generate  a  pattern 
with  a  smooth  rise  from  the  null  (to  avoid  sensitivity  to 
satellite  platform  pointing  errors,  or  movement  in  the 
satellite  position  versus  time) ,  the  first  pattern  might  be 
chosen  because  it  provides  the  smoothest  rise  by  limiting 
discrimination.  The  second  pattern  might  be  selected  to  give  a 
smooth  null  with  moderate  discrimination.  If  a  sharp,  deep 
null  were  desired,  the  pattern  of  case  three  might  be  chosen. 
Consequently  the  algorithm  provides  great  flexibility  in 
generating  the  null  shape. 

4.8  CONCLUSIONS 

Initial  results  shown  that  excellent  performance, 
expressed  as  mean  square  error  between  desired  and  achieved 
radiation  patterns,  can  be  achieved  within  the  theoretical 
resolution  of  the  MBR  antenna  aperture. 

4.9  LIMITATIONS  OF  THE  MBR  ALGORITHM 

There  are  several  limitations  of  the  proposed  MBR 
algorithm.  One  shortcoming  is  that  the  algorithm  does  not 
consider  overall  system  performance  in  generating  the  beam 
weights.  The  algorithm  simply  provides  an  LMS  match  to  some 
specified  directive  gain  pattern  by  a  functional  minimization 
technique.  However,  the  algorithm  does  not  consider  such 
large-scale  system  parameters  as  the  composite  network  data 
throughput  rate  or  the  car r ier - to-no i se  density  ratio,  C/N 
for  all  links  in  the  network.  Thus,  if  the  input  desired 
pattern  is  physically  non-real izable  due  to  antenna  aperture 
size  limitations,  the  algorithms  will  simply  provide  a  LMS  fit 
to  the  required  input  gain  pattern.  The  resultant  gain  pattern 


can,  however,  be  used  to  provide  guidance  as  to  what  "new"  gain 
pattern  should  be  requested. 


There  are  also  limitations  induced  by  the  format  of  the 
antenna  data  itself.  One  such  limitation  is  that  frequency 
dependent  effects  are  not  considered  in  the  current  analysis. 

The  performance  of  each  singlet  beam  is  also  a  function  of  the 
frequency  at  which  the  antenna  is  excited,  but  singlet  data 
measurements  used  here  correspond  to  a  single  frequency  (at  the 
center  of  the  band  of  interest) .  If  the  antenna  frequency 
response  is  relatively  broad  (as  with  the  DSCS  III  61-element 
MBR) ,  the  resultant  antenna  patterns  are  expected  to  be  quite 
accurate.  However,  if  the  antenna  patterns  are  highly 
frequency  dependent,  then  the  technique  examined  here  would 
have  to  be  extended. 

Another  limitation  due  to  the  antenna  data  is  that  the 
terminal  locations  can  be  specified  to  only  within  0.2°  in 
azimuth  or  elevation.  This  limitation  arises  because  the 
singlet  antenna  data  are  provided  for  points  0.2°  apart. 

This  means  that  terminal  locations  specified  in  the  scenario 
data  and  the  actual  location  of  the  terminal  may  be  differ  by 
+0.1°.  If  there  is  a  significant  difference  in  the  gains 
achieved  at  the  two  point,  the  algorithm  may  not  actually 
perform  as  well  as  the  results  suggest.  To  overcome  this 
limitation,  interpolation  between  measured  samples  in  the 
singlet  data  could  be  used. 

The  results  may  also  be  optimistic  because  the  algorithm 
does  not  consider  the  effects  of  beam  weight  quantization.  The 
algorithm  assumes  that  a  continuous  set  of  beam  weights  is 
allowed,  but  the  DSCS  III  MBR  has  six-bit  quantization  on  the 
in-phase  and  quadrature  beam  weight  components.  The  effect  of 
quantization  generally  diminishes  the  gains  to  desired 
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terminal,  increases  the  gain  to  interfering  terminals,  and 
changes  the  phase  throughout  the  FOV.  Future  research  should 
consider  the  effect  of  beam  weight  quantization. 

One  limitation  previously  mentioned  is  that  the  algorithm 
considers  only  the  desired  directive  gain,  but  not  the  desired 
phase  response  at  a  given  terminal  location.  The  ability  to 
specify  the  phase  response  would  be  particularly  useful  in 
investigating  such  techniques  as  phase  tapering  to  shape  null 
regions.  The  B  matrix  weighting  technique  described  in 
Reference  5  and  introduction  of  spatial  fields  described  in 
Reference  5  provide  benefits  analogous  to  the  effects  of  phase 
tapering.  An  exact  comparison  of  the  two  methods,  however, 
would  require  further  research. 

In  spite  of  these  limitations,  the  algorithm  provides  a 
practical  technique  to  find  beam  weights  for  the  DSCS  MBR. 

Most  of  the  preceding  limitations  may  be  overcome  with 
reasonable  modifications  to  the  algorithm  and  by  interpolation 
between  measured  samples  of  the  singlet  data. 
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